A typical mechanism for implementing user interaction with a computer may involve the use of a graphical user interface (GUI) associated with a computer program running on the computer. Generally speaking, user interface elements (hereafter, UI elements) are aspects of a computer system or program which may be seen (or heard or otherwise perceived or interacted with) by an end user and used to control the operation of a computer system or program through commands and other mechanisms. A graphical user interface emphasizes the use of graphical UI elements which are responsive to user input (e.g., mouse events, keyboard data entry etc.) for interacting with a computer system or program. Common UI elements familiar to most users include, buttons (e.g., “OK” or “Cancel), edit boxes, list boxes, combo boxes, scroll bars, pick lists, pushbuttons, radio buttons and components of World Wide Web pages (e.g., hyper-links, documents and images).
In a typical computer program it is not uncommon to encounter literally thousands of such UI elements. Also, some of the same UI elements may appear multiple times as part of different composite UI elements depending on a current context of the program's use. Also, the same UI elements may appear in other computer programs as well. Nevertheless, each instance of a UI element may need to be uniquely identified for various reasons such as programming the functionality of the program hosting such UI elements, testing such a program or for use in otherwise identifying the particular UI element to another program module in communication with the host program. For instance, Assistive Technology (AT) software, like screen readers, screen enlargers or alternative input devices, as well as test automation programs that communicate with application programs may need to clearly identify UI elements hosted within the application programs. More particularly, in one potential scenario, suppose an application program tester has found a defect related to a UI element in an application program and wants to continue to exercise the application at the same UI element to determine whether the defect was an aberration or permanent. In order to do so, the tester may want to reboot his computer and get back to the same defective UI element for testing.
However, currently there is no reliable mechanism of identifying these UI elements across reboots, across instances of an application, across localized versions, and across builds. Currently, depending on the operating system platform, it is possible to use a combination of role, name, location, position among siblings (e.g., 4th child among n children), and other things. However, none of these properties on their own are sufficient; and many of them are fragile (e.g., location, name).
Thus, there is a need for systems and methods to provide identifiers for a UI element that persist across instances of an application, across localized versions, across builds, across reboots and other similar events. More particularly, there is a further need for platform level Application Program Interfaces (APIs) that can be used by a client program to receive persistent identifiers related to a source program and use such an identifier to locate a particular UI element in a target program.